A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the United States Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
1. Field of the Invention
The present invention is directed to computer systems, and more particularly, to a method, apparatus, and computer program product for replacing a dynamic link library (DLL) of a first computing environment with a DLL of a second computing environment that can be invoked by a calling application in the first computing environment in a manner that is transparent to the calling application. The present invention is particularly useful in systems in which the first computing environment is emulated within the second computing environment.
2. Description of the Prior Art
Most computer operating systems provide a dynamic link library facility that enables a computer programmer to provide certain executable procedures and functions in the form of a library that is separate from the applications that execute on the computer. Typically, an application is dynamically linked to the library at run-time, so that the application can call one or more of the procedures and functions that are exported by the library. Exported procedures are referred to as entry points into the library. Unlike regular applications, which are generally executed from the beginning, a library can be entered at any entry point. Libraries allow a computer programmer to keep certain types of procedures and functions that are commonly used by numerous applications in a single library code file that all applications can use. This eliminates the need to duplicate code for common functions in each application.
FIG. 1 shows an exemplary computer system. 10, such as a Unisys A Series or ClearPath HMP NX computer system, that runs the Unisys MCP operating system 12. The computer system 10 is referred to herein as an MCP server. The MCP operating system provides a dynamic link library facility of the type described above. This facility allows an application program 14 to call one or more exported procedures 18a, 18b, 18c from a library code file 16. Each exported procedure has a procedure name (e.g., xe2x80x9cP1xe2x80x9d, xe2x80x9cP2xe2x80x9d, xe2x80x9cP3xe2x80x9d, etc.) and may receive one or more arguments or parameters (e.g., xe2x80x9carg0xe2x80x9d, xe2x80x9carg1xe2x80x9d, xe2x80x9carg2xe2x80x9d, etc.). Each argument has a predefined data type. The name of a procedure, its arguments, and their data types represent an interface, sometimes also commonly referred to as a signature, for the procedure. Any call made to a given library procedure from an application must adhere to the procedure""s interface. That is, the correct name of the procedure must be used in the calling application, and the number and data types of the arguments passed to the procedure by the calling application must match those of the procedure""s interface. For purposes of illustration herein, the interfaces of each of the exported procedures 18a, 18b, and 18c of the library code file 16 are represented respectively at 20a, 20b, and 20c. 
Referring still to FIG. 1, when the source code for a library is compiled in the MCP operating system environment, the compiler generates a directory 22 that becomes part of the executable library object code file 16. The directory 22 contains a description of each of the exported procedures in the library, including the name and type of the procedure and a description of its arguments.
When the source code of an application program that calls one or more procedures of a library is compiled in the MCP operating system environment, the compiler generates a template 24 that becomes part of the compiled application program object code file 14. The template 24, like the directory 22, contains information about the library 16 and any declared procedures that it will call in the library. Specifically, the template 24 contains a description of the attributes of the library 16 and a description of each procedure in the library that the application program has imported. For each imported procedure, the template specifies the name and data type of the procedure and a description of each of its arguments.
FIG. 2 is a source code listing of an exemplary dynamic link library for the MCP operating system environment. This exemplary library exports two procedures, one of which is a typed procedure (TYPED_PROCEDURE (BOOLEAN_PARAM, INTEGER_PARAM)) (lines 201-206) and the other of which is an un-typed procedure (UNTYPED_PROCEDURE (REAL_PARAM, INTEGER_ARRAY_PARAM)) (lines 207-212). The typed procedure has two argument (sometimes also called parameters), one having a BOOLEAN data type and the other having an INTEGER data type. The untyped procedure also has two arguments, one having a REAL data type and the other having an INTEGER ARRAY data type.
FIG. 3 is a graphical depiction of the contents of the directory 22xe2x80x2 that is created when the source code listing of FIG. 2 is compiled in an MCP operating system environment. As shown, the directory is a single block of data having several sub components, including a Header block 25, an Exports block 26, a Types block 28, and a Names block 30. The Header block 25 appears physically at the beginning of the directory 22xe2x80x2 and contains, in fixed locations, pointers to the other sub components. The Names block 30 contains the names (character strings) of the various exported items. The Types block 28 contains encoded descriptions of the types of the exported procedures and their parameters. Finally, the Exports block 26 contains an entry for each exported item. Each entry in the Exports block 26 contains a pointer to the name (within the Names block 30), and the type signature (within the Types block 28) of the exported item. The type signatures are in the form of a recursive description, with the kind of item (procedure, function, etc.) at the top. This is followed by the return value type, if any, and then the parameters in order. If the parameters have additional structure (such as an array), that information is included within the description for the parameter. Each element of a type description carries a length indication which includes any subordinate information. As mentioned above, the name of an exported procedure and the specification of the data types of its parameters define an interface, or signature, for the exported procedure.
FIG. 4 is a graphical depiction of the contents of the template 24xe2x80x2 that is created when the source code of an application program that imports both of the exported procedures of the library of FIG. 2 is compiled in the MCP operating system environment. As shown, the template 24xe2x80x2 includes a Header block 34, an Imports block 36, a Types block 38, a Names block 40, and an Attributes block 42. The Header block 34 appears physically at the beginning of the template 24xe2x80x2 and contains, in fixed locations, pointers to the other sub components. The Names block 40 contains the names (character strings) of the items that the application program has declared as imports. The Types block 38 contains encoded descriptions of the types of the imported procedures and their parameters. The imports block 36 contains an entry for each imported item. Each entry in the imports block 36 contains a pointer to the name (within the Names block 40), and the type signature (within the Types block 38) of the imported item. As in the directory 22xe2x80x2, the type signatures are in the form of a recursive description, with the kind of item (procedure, function, etc.) at the top. This is followed by the return value type, if any, and then the parameters in order. If the parameters have additional structure (such as an array), that information is included within the description for the parameter. Each element of a type description carries a length indication which includes any subordinate information. Finally, the Attributes block 42 contains information about the attributes of the requested library. One series of attributes, for example, specifies the file name of the library code file to which the application will dynamically link.
In the MCP operating system environment, on the first call of an imported procedure of the library by a calling application or at an explicit linkage request, the calling application is suspended. The description of the imported procedure in the library template of the calling application is then compared to the description of the exported procedure in the directory of the library code file to ensure that the parameters match. If not, a run-time error is generated and the calling program is terminated. If the parameters match, then the library code file executes up to the FREEZE statement (see FIG. 2, line 214). All of the exported procedures that are declared in the calling application are then dynamically linked to the calling application, and the calling application resumes execution. Because the linking is performed dynamically at run-time, the library is generally referred to as a dynamic link library (DLL). Other operating systems support a similar notion of dynamic link libraries. For example, the Microsoft Windows NT operating system environment supports the use of Win32DLL s which function in an analogous manner. However, the parameter matching that is performed in the MCP environment is not performed by the Windows NT environment, leading to the possibility of inadvertent errors during program execution.
Today, it is becoming increasingly common to emulate one computing environment within a second computing environment. Because of the incompatibilities between the emulated and native computing environments, it normally is not possible for an application program executing in the emulated computing environment to invoke the exported procedures of a dynamic link library executing in the native computing environment. In many situations, however, it may be desirable to replace the functionality provided in one or more dynamic link libraries of the emulated computing environment, which otherwise would have to be executed by emulation, with a dynamic link library in the native computing environment that provides equivalent functionality in that native machine environment. For example, in many computing environments, networking functionality is implemented in the form of a dynamic link library to which applications link to obtain networking services. When such a computing environment is emulated within another computing environment that employs its own, native dynamic link library to handle networking functionality, it would be desirable for an application program executing in the emulated environment to link to the native dynamic link library, rather than executing its own library code via emulation. This would result in much faster execution of network operations by an emulated application. It would also be desirable if such a capability could be achieved in a manner that is transparent to the calling application of the first computing environment, i.e., in a manner that does not require any changes or re-compilation of the calling application. The present invention provides such capabilities.
The present invention is directed to a method, apparatus, and computer program product for replacing a dynamic link library (DLL) of a first computing environment with a DLL of a second computing environment that can be invoked by a calling application in the first computing environment in a manner that is transparent to the calling application. More specifically, in accordance with the present invention, a first DLL of a first computing environment, which exports one or more procedures that an application program executing in the first computing environment can call, is replaced with a second DLL that executes in a second computing environment. The second DLL is generated based on information contained in a directory of the compiled object code of the first DLL. The exported procedures of the second DLL have interfaces that are identical (from the perspective of the calling application) to the interfaces of the corresponding exported procedures of the first DLL, but the exported procedures of the second DLL comprise native code of the second computing environment. The calling application executing in the first computing environment is then linked dynamically to the exported procedures of the second DLL in the second computing environment in a manner that is transparent to the calling application. The second DLL thus effectively replaces the first DLL. The present invention is particularly useful in systems in which the first computing environment is emulated within the second computing environment.
In a preferred embodiment, the second DLL is generated as follows. Information contained in the directory of the compiled object code file of the first DLL is extracted in order to identify its exported procedures and their respective interfaces. A source code skeleton of the second DLL is then generated from the information extracted from the directory of the compiled object code file of the first DLL. In accordance with the present invention, the source code skeleton of the second DLL comprises, for each exported procedure to be reproduced in the second DLL, (i) a parameter matching routine that, when invoked, verifies whether a calling application in the first computing environment was compiled with an interface description for the exported procedure that matches the corresponding interface description for that exported procedure in the second DLL; (ii) an interface jacket routine that maps arguments of the exported procedure supplied by a calling application in the first computing environment into corresponding arguments that can be manipulated properly by the code of the second DLL in the second computing environment; and (iii) a prototype declaration for the exported procedure. Native code of the second computing environment is then added to the source code skeleton of the second DLL to establish the functionality of each exported procedure of the second DLL within the second computing environment. The second DLL thus reproduces the exported interface of each exported procedure of the first DLL, but contains native code of the second computing environment in the body of each procedure. The completed source code of the second DLL is then compiled in the second computing environment. Further in accordance with the preferred embodiment of the present invention, linking of the second DLL to a calling application in the first computing environment is performed as follows. The compiled second DLL is located and loaded in the second computing environment. Next, the procedures of the DLL that are imported by the calling application are identified. For each exported procedure imported by the calling application, the corresponding parameter matching routine exported by the second DLL is invoked. If the parameter matching routine executes successfully, then the parameter matching routine will return an entry point for the corresponding interface jacket routine for this exported procedure. The current entry point for this exported procedure in the calling application is then replaced with the entry point for the interface jacket routine in the second DLL. When the calling application subsequently calls one of the exported procedures, the interface jacket routine for that procedure in the second DLL will execute. The interface jacket routine will encapsulate, or map, the parameters supplied by the calling application into equivalent parameters that can be manipulated by the native code of the second DLL. The code comprising the body of the exported procedure then executes.
The method of the present invention may be implemented in the form of a code generator that performs the source code generation for the second DLL and a linker that links the second DLL to a calling application in the first computing environment in a manner that is transparent to the calling application. The present invention may also be embodied in the form of program code that, when executed on a computer system, performs the method of the present invention.
Additional features and advantages of the present invention will become evident hereinafter.